一种在FPGA设计中解决holdtime违例的方式

这是一篇不太专业的分享，从IC到FPGA虽说有很多相通之处，但具体到一些实现细节上，还是存在较大的区别的，比如holdtime的收敛问题。我长期从事IC设计工作，FPGA只是在做原型验证的时候偶尔用到，应该说是处在一个相当业余的段位，不过我觉得还是可以把这点业余的经验记录下来，也许有人在工作中遇到过同样的困扰，看完能起到抛砖引玉的作用。

数字电路工程师经常要面对的问题之一就是所设计电路的Timing是否收敛，Timing问题主要又在于setup time和holdtime两个方面。在IC设计中，setup time与前端设计关系较为紧密，通常在综合阶段就会把setup time考虑进来，在过约束条件下达成收敛再交付后端做CTS和PR，以留有足够的裕量供后端调整，而hold time违例在前端综合时一般不做处理，只在后端进行修复，最常见的修复方法就是在数据路径上插入buf以增大数据路径上的延时。因为IC设计的后端流程人工干预度非常高，时钟网络和布局布线都可以零活调整，总有一种方式可以把问题处理好。

在FPGA设计中，因为FPGA芯片的时钟网络是固定的，设计上相对就缺少了很多零活性。这对于setup time的影响还不是很大，通过调整代码问题一般都能得到解决，实在不行还可以降频，不至于造成电路完全无法工作。而holdtime的违例在FPGA中就显得比较棘手，holdtime不满足简单来讲就是数据路径延时太小，在当前时钟沿的采样稳定窗口未结束时，下一个数据跳变就已经到达，而使寄存器采样到不稳定的数据。因为holdtime不满足影响的是当前采样时钟沿，所以它与时钟频率无关，即使降频也不能够解决，而IC后端常用的修复手段在FPGA中几乎没法使用，虽然工具提供了一些特殊的综合策略来应对这个问题，但效果通常并不是很理想。比如我最近正在做的一个IC项目需要做FPGA原型验证，便又碰到了holdtime无法收敛的问题，尝试了vivado内置的各种综合与布局策略后，并没有得到任何改善，无非是slack在不同的路径之间轮换罢了。

vivado内置的策略无法解决，就只好另辟蹊径：选中其中一条路径其具体的延时如下所示。

可以看到destination clock path比source clock path慢了0.6ns，而destination clock path中，时钟从源端到达寄存器的clock端，相对于source clock path在LUT3和BUFG后的线延时非常大，在LUT后增加了近2ns，在BUFG后增加了近1ns。这种情况我们在IC后端设计中，在source clock path的data path中插入适当的BUF就可以解决，但在FPGA中好像没有办法进行这种操作（也许FPGA也可以，但我作为菜鸟确实不清楚）。既然不知道怎样增大data path的延时，那是否可以减少clock path的延时呢？那两个1.939ns和0.811ns的延时，如果能压缩掉一个，问题不就解决了。但FPGA的clock tree是固定的，全局时钟缓冲器BUFG也不会遍布芯片的各个角落，所以首先需要了解这条路径在芯片中的物理位置。右键选中这条路径上的BUFG，在快捷菜单中选择Mark，在place视图中标记该单元，可以看到BUFG在距离destination比较远的位置。

上图可见，destination clock path中的BUFG在上图黄色菱形标记处，register在逻辑中部红色箭头区域。从BUFG到register的clock端要经过图中白线所划过到距离，这段走线的延时是相当大。分析到这，解决措施就有方向了，如果我把逻辑布局移动到更加靠近BUFG的区域，那线延时自然就被压缩，问题也许就解决了。而这种改变布局位置的方法vivado是有提供的，那就是pblock（实际上我不知道pblock的常规作用是什么，但这里我觉得可以一试）。

从主菜单的Tools项调出Floorplaning子菜单，选择Create pblocks进行手工创建，即可打开pblock对话框。pblock的创建是基于设计的层次来的，找到我需要优化的路径所在的模块，选中它后，vivado即可为该模块创建单独的布局区域。

创建完成后，依然是在Floorplaning这个菜单中，选择Place pblocks，对刚才创建的pblock进行放置。

点击OK后，即可以在布局视图界面通过鼠标拖动的方式，将该pblock移动到任意位置。按照我的优化目标，我将该模块的pblock拖动到靠近之前标记的BUFG附近。

做完如上一系列操作后，vivado会在xdc文件中生成对应的约束，保存该xdc文件，后面再进行布局时会自动加载该pblock。

重新启动综合流程，最后得到的结果，holdtime的违例已经全部得到完美解决。

打开布局视图也可以发现，逻辑分布和之前的已经大不一样，逻辑围绕在BUFG的周围，那么clock path的latency自然小了，结果与之前的分析是一致的。

其实我不太清楚这种处理方式是否合理，或者说这是一种常规操作只是我作为FPGA菜鸟不知道罢了。不过就这个holdtime的问题，确实困扰了我很长时间，在网上找过很多相关讨论，也咨询过一些FPGA工程师，均没有很好的解决。也有人说holdtime在FPGA中，如果slack不是特别大的话可以忽略，但我在IC设计中形成的完美主义实在无法容忍这种情况。

如果有在项目中遇到这类问题不好解决，不妨一试。